The Interactive Network Design Manual

How To Secure Your Network

Writing a Security Policy

Following are basic steps for developing a security policy:

1. Assess the types of risks to your data.

2. Identify the vulnerabilities of your system and possible responses, including operating system vulnerabilities (for Unix, NetWare and Windows NT), vulnerabilities via clients and modems, internal vulnerabilities, packet sniffing vulnerabilties and how you will test for vulnerabilities. Possible responses include encrypting data and authenticating users via passwords and biometrically.

3. Analyze the needs of user communities.

4. Write the policy.

5. Develop a procedure for revisiting the policy as changes are made.

6. Write an implementation plan.

7. Implement the policy.

Risk Assessment

First, assess the situation. Ident ify the data that is potentially at risk and how it could be compromised within the context of access that exists or when additional access is added. Clearly understand the worst-case consequences of the data being compromised.

For example, you may publish an online catalog and have confidential data also on your network. You want to publicize the catalog and get it in front of as many would-be customers as possible. If it is destroyed or vandalized, there may be some embarrassment, or in the worst case, you may lose some business from the lack of access to the information. But if the data is backed up, and you have restoration procedures in place, then it is only a matter of determining how much time it will take to restore it, and how much potential business could be lost during that time.

Proprietary or confidential information is an entirely different matter. You do not want such data in the wrong hands as such access it could have a devastating effect on business. In this case, backups are not going to do you a bit of good.

Identifying and Addressing Vulnerabilities

One of the biggest potential vulnerabilities to your data is the operating system that the data is stored on and the app lications that run on the operating system. If someone can take control of the operating system, there is a good chance that he or she can have his or her way with anything else that the operating system supports. And, a poorly designed application can often provide the hooks needed to access the operating system.

The most common operating systems that act as hosts for data are Unix, Novell NetWare and Windows NT. They each have their own advantages and disadvantages and you will want to become intimately familiar with all of the weaknesses of the operating systems that you support.

Unix:

Although no networked system can be guaranteed to be completely secure, some systems are worse than others. The Unix operating system, which was engineered to provide easy communications and access usually comes with Internet (TCP/IP) access by default. This is the protocol that all devices on the Internet use to communicate. There is also a great deal of public domain software available for Unix that was written with easy access as a greater priority than security. There are also many versions of Unix, each with its own unique problems. The advantage of Unix is that many of its vulnerabilities have had decades of testing, so the vulnerabilities are well-known.

If your hosts are running the Unix, be vigilant about understanding your exposure. Although it is quite possible to make a Unix system just as secure as any other system, such an effort requires a lot of time and effort. And once you have your data secured, you will want to constantly watch for announcements of newly discovered security problems by:

a. Subscribing to CERT's advisory service and researching past advisories

b. Subscribing to Security listserve (subscribe firewalls-digest in body of email to Majordomo@GreatCircle.COM)

c. Watching the comp.security news group

d. Keeping in close touch with the vendor of your version of Unix

e. Reading the NCSA Home page, which also has useful information

f. Monitoring your Unix hosts for suspicious activity

Novell NetWare:

It is likely that the network that you are considering for connection to the Internet will have one or more Novell file servers. If these devices are running only the standard IPX protocol, they will be incapable of communicating on the Internet. This can be an inconvenience, but it makes Novell servers very secure from direct Internet attacks, which rely on the TCP/IP protocol. Although a Novell server is an unlikely target of an Internet attack, it's security cannot be taken for granted. It is also vulnerable from inside your network.

One way that data on a Novell server can be compromised from an Internet attack is via a Unix server on the same network that has been compromised. From such a base, it is fairly easy to run a packet-sniffing program that can collect and decode IPX packets going to and from the server. The data from these packets can then be extracted. If the Novell server is on the other side of a router, or if both devices are on dedicated switched ports, then the IPX packets won't appear on the LAN or segment that the Unix host resides on, making it impossible to sniff the packets unless there is a client talking to the Novell server on the same segment or LAN as the Unix server.

Another possibility is that a Novell client program could be loaded on the Unix server. This program could be used to access the Novell server directly, especially if passwords have been sniffed on the network. Of course a lot has to happen in order to set up this environment. It assumes the hacker has gained root access to the Unix host, and put the network interface into promiscuous mode in order to sniff for packets on the network. It also assumes that the binary files for the Novell server program were FTP'd on to the host and installed, all without the Unix systems administrator noticing.

It is also possible that the Novell se rver has a TCP/IP stack running on it. If this is the case, then it will be capable of communicating with other devices on the Internet and the internal networks running TCP/IP. You will want to add the NetWare Loadable Modules (NLMs) that provide these communications one at a time, after you research the vulnerabilities.

With NetWare IP it is possible to access standard Novell file and print services via TCP/IP. If you are adding NetWare IP or any other IP access to your server, you will need to consider the added access that this could provide from the Internet. You will want to filter out TCP and UDP port 396 from Internet access. (These are the ports that NetWare IP uses.) You also may want to consider installing NetWare 4.x (if you haven't already), as it is more secure than 3.x. NetWare 4.x has also been submitted for C2-level evaluation by the National Computer Security Center.

Windows NT:

It is very common for an NT, Windows95 or Windows for Workgroups client to be using TCP/IP for sharing files and printers. If TCP/IP is being used, the devices on the Internet can probe the TCP and UDP ports (137, 138, 139) associated with these communications. If you want to see if this is possible, visit MWC's site at http://www.omna.com/yes/mwc/info/, which will automatically probe these ports on your machine. If your Internet firewall is set up to allow these ports, you will know immediately. (It is highly recommended that you filter these ports out at your firewall). MWC also offers scanning software and services specifically for NT environments.

Many of the same programs that run on Unix systems have been ported to the NT environment, allowing it to support many TCP/IP-based services such as FTP, the Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP) and others. Unlike Unix, NT was designed after security became a big issue. If you do a search on "security" at www.microsoft.com you will see that this topic is som ething that Microsoft has given a lot of attention. The fact that NT has been evaluated for a C2 level of security demonstrates that Microsoft has at least made a serious effort. This does not in any way automatically make NT an inherently secure environment. In fact the MWC site and others list bugs that compromise the security of an NT system. You still must follow precautions in order to ensure that you are not vulnerable.

Clients and modems:

Generally DOS/Windows-based clients machines don't offer server functions, so it's less likely another device will initiate communications with them. MS Windows file and print sharing function, however, does open up this possibility, as it can use TCP/IP as its transport. To check for vulnerabilities from the Internet for WFW and Win95, visit the MWC site mentioned above. And, if a user leaves a modem connected to their PC at work, with remote control software running, even the most restrictive firewall can be undermined. Once that PC is accessed, the hacker will also have access to any host on the network that the PC was logged into.

Internal threats:

Many of the risks discussed above also apply to your internal network, which could pose a greater threat to your security than Internet attacks. One reason for this is internal users have direct access to the physical LAN and to hosts on the LAN. It is also easier to acquire passwords. When you develop your security policy, take the opportunity to deal with non-network related security issues as well, such as making sure that users don't write passwords down on Post-it Notes stuck to their monitors or give them out.

One way to deal with this is to design your network so that only certain devices have network access to particular hosts. This can be accomplished with internal firewalls, or routers (albeit with a performance penalty) as well. In this way, it impossible to get into particular hosts from certain clients, even if they do find out the password.

Pa cket sniffing:

Packet sniffing, a possibility on the Internet, could be an even greater threat on your internal network. Most Ethernet networks broadcast all traffic to and from all nodes throughout the network. Separating the network into subnets through a router or switches can give you some control over this. Another approach is to give everyone on the network a connection to a dedicated port on a switch. This allows you to mix devices on the same network and eliminate the ability to sniff packets. Broadcasts will still appear on every port of a switch giving clues about the hosts and their locations on the network, but it takes a much greater level of sophistication to take advantage of this information. Your security policy should address who is allowed to use packet sniffers.

Packet sniffers are an invaluable tool for troubleshooting network problems, but in the wrong hands they can acquire information from the network that you might not normally want to share. Keep in mind that there are public domain sniffers available that can be loaded onto a PC, so locking up your analyzers is still no guarantee.

Testing for vulnerabilites

There are a number of products and services available that you can use to test for vulnerabilities. You can use them to test for vulnerabilites that you may not know about as well as to test the solutions that you have implemented. The SATAN program, for instance, was designed specifically for this purpose. There are also a number of commercial products that have been developed to scan for vulnerabilities in your network, such as Bellcore's Pingware (http://www.bellcore.com/SECURITY/pingware.html), Internet Security Systems Products (http://iss.net/) and Qualix Group's Netprobe (http://www.qualix.com/sysman/product/netprobe.htmld/index.html).

Many consultants will do this f or you. If you hire a consultant to secure your network, you may want to hire a different consultant to check for the vulnerabilities.

Updated November 15, 1996